Alex Byrne
Youth Services Librarian
Twitter: @HeofHIShirts
github.com/HeofHIShirts
for Open Source Bridge 2017
22 June 02017
#earlyliteracyOSB
#osb17
The Standard Disclaimer
A few things before we begin.
- The opinions expressed in this presentation are not necessarily those of my employer, whom I very much like working for. Please do not mistake my opinions for theirs.
- I have attempted to accurately convey the opinions of others based on their published work. If I'm wrong about this, please let me know so I can make corrections.
- No logo or image used in this presentation, or mention of any other project, implies endorsement from the owners and/or maintainers of those projects.
Early Literacy
Time to peel back the curtain a bit on the magic that is the public library Story Time. Public Librarians are forever attempting to balance between things that are enjoyable and entertaining for children and their caregivers and things that will help those same children get ready for school and equip their caregivers with the tools to help them get and maintain school readiness. The good thing is, for the most part, public librarians can mash the two together and create things that are both fun and educational in their Story Time programs.
Underneath each librarian's Story Time is a very strong lattice of research and practice that informs their presentations and allows them to slide all of the useful information to children and caregivers without having to call attention to it in any sort of way that breaks the flow. The focus of Story Time is to develop early literacy, a set of skills that lay the groundwork for recognizing that certain squiggles are written language, translating those squiggles into words, and associating those words with concepts, experiences, and objects in the world firmly enough that the word can serve as a proper abstraction for the thing itself, while also giving practice at making squiggles that can do the same thing for others. Done well, it means that kids who go to Story Time enter school ready to read on a Kindergarten level, and have practice with prosocial behaviors, emotional regulation, and other skills that will make their school experience less stressful for themselves and their teachers.
The process by which one acquires language is pretty similar, regardless of whether it is a primary language, a secondary language, or a computer programming language. Yet, the older we get, the more we have to fight our lack of neural plasticity and the less likely it is that we're going to be in an immersive environment where we will be able to pick up the language natively through practice and feedback. Considering all of this research that's helpful in getting children ready to read, why not try and apply its knowledge to the domain of getting beginning developers ready to program?
Five Practices
I'm taking as my inspiration the Five Practices of Early Literacy, and if you'd like to see a great poster of those practices, you can go down to the Multnomah County Library that's only a few blocks away from here and see it at work (and possibly catch a program or two). Those of us on looking in digitally will need to go see it at the Multnomah County Library's Website, where you can obtain your own copy.
The order will be a bit different than on the poster, but these five practices, done vigorously, are likely to produce a roubst language experience for anyone, young or old.
Play
A lot of people come to coding, or computing in general, as something they learn to help them with a task, or to form an idea, or to make a piece of software or hardware do exactly what they want it to do, and not some other person's idea of what to do. When you keep getting something that is almost, but not quite, tea, at a certain point there comes the desire to do it yourself. A lot of that initial spark is driving someone to learn, and if you can feed them lessons that will help them get the skills they need to realize whatever is in their head, you have a much better chance of getting them to stick with it to the end. Desire is a powerful motivator, and play is a great way of getting people to express and solve their desires. We'll come back to it at the end, but keep it in mind as we go through the other key words.
Talk
The very first exposure a child gets to language is through hearing other people talk. TED has a playlist of talks about the genius of babies, but the one I'm going to focus on right now is Patricia Kuhl's "The Linguistic Genius of Babies", because it focuses on an important part of language acquisition - parentese. Parentese is a very specific form of language characterized by higher pitch, elongated vowel sounds, and precise speaking pattern. It's vocally different than how you talk to your pets. If you've ever been around a smiling baby, you've likely spoken parentese.
Here's the neat thing, and a short clip from the TED talk will illustrate this: Parentese is worldwide, and is present no matter what language you speak. If you are looking for the universal language of parenthood, there you are.
I'm not saying that you have to speak parentese to beginning software learners or novice coders. They might be quite offended with you doing that, actually. What beginners often need, though, is not just to be set in front of a tutorial and told to come back when they're finished, but to have someone on hand to bounce questions off of or to talk them through problems and exercises so that they understand. Learners often pick up useful information by observing someone else at work using the language, but they can't just be there while you do things and learn it all by observation alone.
One of the best skills a librarian has that goes mostly unnoticed is that they're really great at narrating themselves to others. When demonstrating (sometimes for the sixteenth time) how to go through a procedure to obtain resources or run searches, librarians narrate what they are doing and why. When reading a book to tiny people, youth services librarians often ask questions about what the characters are doing or feeling, so that the tiny people can use both the text and the pictures to decode what's going on in the story. (Recommendations for this concept are Antionette Portis's "Not a Box" and "Not a Stick".) Key information about the story is often communicated visually in a picture book, and sometimes in complete contradiction to the text. (Jon Klassen's "This is not my hat" and "I want my hat back" tell intersecting stories, one in text, one in pictures.) By providing scaffolding through narration, the librarian provides context and reasoning for the actions they're taking. By asking questions at regular intervals, the librarian can check to make sure understanding is happening and adjust to include perspectives they may not have been taking into account before.
Every language has its benefits and quirks that differentiate it from others and attract followers and adherents. Compiled versus interpreted languages, syntax choices, the use of whitespace as enforcement of hierarchy, speed, flexibility, and so forth all go into the creation, use, and evangelism of a particular language. Idioms, colloquial expressions, and jokes are often the hardest parts of learning a spoken language, and similarly, the quirks and Ways of doing things in a particular software language are often the most difficult. My early Ruby, for example, looked a lot more like BASIC, with layers of nested if statements, each to their own line. Once my instructor pointed out to me the logic operators, and the way that Ruby treats objects and their attributes, more than a few layers of if collapsed into a single, much more readable, line. They both worked, but it was the difference between being able to ask where the bathroom is and being able to share a joke.
Talking and explaining things to your learners, and letting your learners try to explain things to each other, is the best way to help them learn. So if you get the opportunity to have someone shadow you and ask you annoying questions about what you're doing and why you're doing it that way, take up the opportunity. (And request it all gets documented. Trust me.) By talking through things with someone who doesn't have your expertise, you shore up your own knowledge and help someone get more of their own. That leads to literacy.
Sing
Very closely related to talking is singing. Indulge me for a bit.
If you're Happy and you Know It...
Of the people here who know that song or something like it, the last time you sung it was probably...a long time ago. Unless you have young children. Then it was only a little while ago.
The staying power of song is greater than we might think. For those who have the joy of remembering the cartoon Animaniacs (or a subscription to a video streaming service that carries it), Yakko's World remains one of the most remembered songs of the time, even though the world's countries have changed significantly since then (Czechoslovakia, for one thing, has broken up). (Things get fixed in the reunion tour versions.) Slightly less well-remembered is Wakko's tour of states and their capitals. Familiar-ish tunes are used as mnemonic devices for large amounts of data. Music songs are often good for remembering significant events. "Our song", for example, or what was playing when a significant event happened. Television shows and movies do it all the time, with music cues, introductory songs, and leitmotifs. You know there's a shark in the water if you hear something like the pulse in Jaws. If you know the Bee Gees song "Stayin' Alive" well enough, you have the tempo for performing CPR.
Another reason to use singing in early literacy is that song allows a learner to hear the syllables of the words more clearly, since many of them are on different pitches and we tend to enunciate our words a whole lot better when we are singing than when we are speaking. The additional clarity helps.
Most of these examples comprise small sets of data, but I could say fairly confidently that most people here have the ability to remember at least an epic poem or two, given the right prompting. If you don't believe me, think of it this way - how many of you have albums that you know back to front, each word, each note, each guitar solo in its place? Considering most albums are at least an hour in length, between music and words, that's a lot of data to go through and remember. You could probably get through a pretty good chunk of Inferno, or the Odyssey, or the Canterbury Tales in an hour. Music is powerful, and helps us retain a lot of information.
So, if need be, encourage your learners to make up silly songs about their syntaxes, or actions. They don't have to sing them out loud in anybody's presence, but it might help make information stick better than just repeating by rote.
Read
Examine this poem. We'll get back to it in a bit, but for now, keep it in mind:
< > ! * ' ' #
^ " ` $ $ -
! * = @ $ _
% * < > ~ # 4
& [ ] . . /
| { , , SYSTEM HALTED
With computer code as a primarily visual language, reading is going to be one of the two primary actions associated with it. One of the best ways to get good at language skills is to read language. Aloud, preferably, for early learners, so that the pronunciations and the symbols meld together properly. This is easier to do, perhaps, with the languages we are used to hearing the sounds and syntaxes of than the ones we are not.
Imagine, for a second, having to discover all the syntax of a language, having perhaps been taught "Hello World" in that language. For some languages, like C++, Hello World has a lot of information about the context of the program baked into the program itself.
// my first program in C++
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
(http://www.cplusplus.com/doc/tutorial/program_structure/)
For other languages, there's not so much context at all.
puts "Hello, world!" # Print out "Hello World!"
Trying to determine what a language can do without having previous examples of the language to build on is going to be a nightmare.
Studying other (hopefully well-documented and commented) code allows us to not only expand our knowledge of the words of code, but also allows us to see how they get put together into intelligible statements and routines, and how those routines then become functions, and then programs past that, assuming someone isn't deliberately obfuscating something in the name of security or complexity. Similarly, early learners learn letters first and their attendant sounds, then use those letters to make words, which then become sentences, paragraphs, and full works.
It's best, of course, to start with beginning readers and simple works that have only a few words and fairly simple grammar and syntax, and that behave in regular ways, and then to add in the weird cases, the more complex operations, and the things that require an understanding of how other languages work later. (Because loanwords and their attendant pronunciations and meanings are a thing in any language, despite the attempts of every Ministry of Language to prevent them from happening.) So, yes, start with The Cat in the Hat, Green Eggs and Ham, and Hamster Huey and the Gooey Kablooie before progressing on to the Gawain-poet, Dante, and Chaucer.
In the realm of learning how software works, tutorials and documentation are the way that people can read about what software does and works, whether those documents are in the program as help files or elsewhere, like web tutorials and demonstration videos. These tools, especially videos, make it easier to see how the flow of software works, rather than having to write up a set of steps / inputs and describe the outputs that would come from that. They have their own problems, of course - if you've ever been a language learner in the company of people who are fluent and speaking at rapid speeds, then you understand why video tutorials are sometimes not very helpful, either, even if you can stop them, rewind them, and play them at whatever fraction of full speed you need to be able to keep up with the keyboarding and explanations going on.
Starting at such a simple-seeming level is frustrating to those who are learning a second or more language, because the fluency they have achieved in one language only helps them show and understand the lack of fluency they have in the other language(s). Some of this can be alleviated with peer mentoring and conversation.
Let's get back to the poem we started at the beginning of this section:
< > ! * ' ' #
Waka waka bang splat tick tick hash,
^ " ` $ $ -
Caret quote back-tick dollar dollar dash,
! * = @ $ _
Bang splat equal at dollar underscore,
% * < > ~ # 4
Percent splat waka waka tilde number four,
& [ ] . . /
Ampersand bracket bracket dot dot slash,
| { , , SYSTEM HALTED
Vertical-bar curly-bracket comma comma CRASH.
Bemmer and Korese, May/June 1990 issue of Infocus magazine
Learning a second language also introduces the problem of faux amis. ("False friends", literally). Faux amis are false cognates, words that look and sound similar between two languages but have entirely different meanings. For example, you buy books in bookstores and borrow them in libraries in an English-speaking country, but you buy books in librairies and borrow them from bibilotheques in French-speaking ones. The same sorts of things happen in programming languages. Python lists and Ruby lists might be the same, but Ruby hashes are not Python dictionaries, even if they look the same.
I often get tripped up between variable assignment (=) and the equals comparison operator (==), because when I learned my grade school math, = meant ==, and nobody actually taught me in high school algebra that when I did things like solving for x, what I ended up with was an assignment statement instead of a comparison.
The poem Waka Waka demonstrates that sometimes language symbols have different meanings - the hash mark (#) appears twice in the poem, but the first time, it's a hash, and the second time, it's a number sign. When it comes to programming, Not to mention some of the additional fun possible in Ruby, where someone could add an additional line of code to the poem before the last one:
<=> => << >> HashWithIndifferentAccess flying saucer hashrocket shovel shovel Mash
which are all conveniently operations and items that either use double symbols or CamelCase to produce their desired effects. Every computer language is weird, sometimes more so than the conventional language it derives from, so any and all tricks that you can use to remember and do things right are fair game.
Learning a second (or first) of anything often results in a lot of frustration, especially when there's a gap in between knowledge of one and knowledge of the second. Really, there's not too much that can be done about that frustration than...
Write
...writing code. Or using the software. Early literacy sees writing as building on the other skills discussed before - talking, singing, and reading (and playing, too), as it is the most complex of the skills of the group (except, perhaps, for play, which increases in complexity as the child does). We do not spring forth from the head of Zeus perfectly able to make glyphs on strange surfaces or machines using odd input methods, and especially not glyphs that are intelligible to everyone else who can read and write the same language.
The ones that are learning how to make marks on paper can still communicate, though. Children that haven't learned how to write can still speak words. Children that haven't learned how to speak words can still understand and use sign language. Even children too young to communicate with sign can still let people know they have issues or needs - a screaming child is not communicating the specifics of their issues, necessarily, but you still know that they're having trouble.
Practicing writing is one of the skills that's a little hard for librarians to wrap their heads around when it comes to audiences that aren't physically able to make the motions that result in letters. Some audiences are just too young to be able to write legibly. For those audiences, there's often a lot of exercises in fine motor control - using paintbrushes, for example, to mimic motions that will be writing-like (such as tracing letters), or to let a child use crayons to make marks on paper, with the focus on controlling the action, so that even if all you get out of the paper is a series of vertical or horizontal marks, the marks are relatively uniform in length, breadth, and pressure applied to the surface. (Drawing the same line repeatedly is harder than it looks, as I found out when an art tutorial suggested it as a way of training the hand.)
For people using computers, learning to use peripherals, whether keyboard and mouse or touchscreen, is the foundation of being able to use software. Understanding the relationship between peripherals and computer actions well enough makes understanding the software easier. Much like how baby sign has made it easier to communicate with the non-verbal child, touchscreens and other direct interaction objects make it easier to use software.
Understanding the software in turn allows us to write programs of our own in computer languages. Using software and peripherals is learning to write letters - there are many ways to get to a particular function or program, and they're all correct, so long as the right end result appears. Computer programming is more akin to calligraphic writing, or writing in systems with stroke orders for characters - the process by which you form the letters is integral to producing the result you want.
Unsurprisingly, there are a lot of different ways of teaching the making of very pretty writing. Similarly, there are a lot of different ways of approaching learning to write code. Whether you use block-based programs, such as Scratch or Blockly, which are more visual and can use human language to represent concepts, or console or code-based programs such as Ruby Warrior or Code Combat, which are about teaching the syntax and grammar of a language, the idea is to be able not only to write code that works, but to understand why the code being written works. Understanding the whys make it easier to transfer skills learned to new domains.
Play (More!)
We loop back around to play again at the end, because the driving spirit of innovation, hacking, coding, making, and many other STEM disciplines often roots itself in "wouldn't it be cool if...?", "I wonder what would happen if...", or "That's interesting...". At the heart of each of these ideas is curiosity and imagination, the twin desires to find out about something and to come up with a way of testing or solving the problem that appears from curiosity. Young children have both of these impulses in spades - it's what drives them to climb to great heights, stick their fingers in electrical sockets, and try to figure out if whatever they have in their hands is edible and nutritious. But also to ask 3D printer companies if they want information on how easy their products are to use by an eight year-old, launch vehicles into space, teach the periodic table to the visually impaired, mentor young girls into making video games, build race-winning solar cars, build solar-powered electric fuel stations, improve the efficiency of their microwaves, and clean fouled water Solving problems, whether on a world revolution scale, on a "goodness this really annoys me" scale, or a "hey, my friend needs something to help them cope with the universe, this might work" scale, is a necessary part of the skillset of being a human.
Entities that make time for play enrich themselves hugely. The Google 20% Time idea, first mentioned in the 2004 IPO letter for Google, has produced many products that people take for granted as part of the Google universe (and more than a few duds). Someone's idea for profile making and interaction at a single college now encompasses a significant population of the world. Recess is necessary for children. Adults need breaks, too, and opportunities to engage in unstructured activities in the same way that kids do. Sometimes a new concept develops into an interesting tangent and helps cement that concept and idea far better than any formal instruction ever would. Play helps work through issues, as well. Children often stage imaginative play that eerily reflects the things they're learning about social life, school life, or other parts of their life that need processing.
The beginning of playing with language are things we've talked about before - picture books who tell separate but related stories and songs, but it also includes jokes and puns (which are signs of literacy), slang, memes, and understanding Yoda or the Russian Reversal.
When it comes to software literacy and computer programming languages, "play" in its most basic form is "Here's an environment with things in it. Manipulate those things and see what happens. If it breaks, reset it back to the beginning and keep going." Which is a lot easier to do, incidentally, on a computer that doesn't cost much, can have its operating system swapped out or reset with each SD card inserted, and isn't meant to necessarily be a daily driver, because people are afraid of breaking the really expensive, mission-critical stuff and not knowing how to fix it.
I learned more than I ever needed to about working with a command line because I liked to play games on the computer in a time where memory limitations often meant having to do interesting command-like fixes or to boot into an environment with minimal memory footprint. My comfort with the console in Linux stems from having used DOS to do all sorts of things beforehand. New syntax, sure, but a lot of what I do in the console now is still in service of making sure games run properly, whether through DOSBox, Wine, or trying (and sometimes failing) to get video acceleration to work properly.
Trying to get games to run has also meant comfort with building computers and swapping out components, and in looking for ways to extend the functionality and the actual life of the technology that I have, often through community-created and -supported methods. (Like transforming an old mobile phone into a portable file server.) Because people want to keep playing with their tech until it physically cannot work any more, or upgraded it sufficiently that it's new tech again. They don't want to be caught in a vendor's lock-in or their planned obsolescence date, forever having to purchase new hardware just to be able to access what they already have. With the advent of consumer-cost 3D printers, a lot of people are rediscovering some of their own playfulness, but also their own problem-solving techniques, as someone with access to a 3D printer might be able to save their favorite piece of technology by printing a new part to replace the one that broke. (And then possibly have to figure out how to connect it to the current bits.)
Each of these skills developed from playing or trying to get games to play makes working with programming languages and software easier. Mod communities are great about this! They give someone a limited environment (ish) to work with and tons upon tons of examples of things that work in that environment. First play happens by smashing together mods to see what they can do together. Then when they interact in unexpected ways, a person dives into the mod code to see what the conflicts are, and then has to start thinking about what they want the mods to do when they interact, which often leads to looking up new bits of code or language and then applying them to see if it works as intended. This cycle of troubleshooting, and the heady surge that comes with finding a way that does work, as well as being able to then talk to the community about what happened, is a great feedback loop for someone just learning, and builds confidence. Just like what happens when you have children or language learners who are starting to communicate and get feedback that their language skills are, in fact, working. Play reinforces learning, and people will learn things they wouldn't ordinarily think they had an interest in, or skills in, in pursuit of that play.
So what?
So how does work in early literacy help inform software and programming literacy? It offers a framework on how people learn and what motivates them to do so. Companies continue to try and find the magic formula that not only produces good work, but also keeps the employees happy enough and compensated enough to not go work for someone else. Superficial understanding of each of these concepts often results in gimmicks, where the attempt is halfhearted and the people it's supposed to motivate end up giving it shade, snark, or sass. Or it produces a massive list of "required" things or a culture that insists on having to know so much before someone begins that are a major turn-off to getting new people (and non-coders) on board or interested in the project, whether as a contributor or a user. These come from rigid applications of a framework that is inherently flexible and personalizable. Each learner comes to literacy their own way, and methods have to be able to work with that.
Talk: Have people on hand whose job it is to onboard new people and help them through the beginning parts of getting acquainted with and contributing to your project or company. Keep them around as troubleshooters for new learners as well, and make them available to bounce problems and ideas off of. As literacy and fluency increase in the learners, they'll start branching out and finding their places (and using rubber ducks to bounce problems off of), but they might come back at any time if there's a new aspect or language or other part they want or need to learn. Human guides and having someone to talk to (even if it's not synchronous) really helps a learner feel welcome and like they are making progress.
Sing: Good memory aids are always welcome. Distribute them widely. Sing the praises of good code, and especially good code from learners and beginners. Be willing to admit when things go sideways, and admit that things go sideways even for the most experienced programmers ever. And, y'know, sing. Out loud. Whether where anyone can hear you or not, because if what you are doing is something that squashes the instinct to sing (it doesn't have to be a nice song, by the way - Kill The Wabbit is perfectly acceptable), then things have gone seriously wrong.
Read: Read lots. Preferably documented, non-obfuscated materials that explains itself and offers visual aids where appropriate. Read style guides and optimization techniques, specifications and pull requests, and the documents on how to document your own work. Find a friendly person and read over their shoulder as they do tasks and accomplish objectives. If it makes sense, listen to audio or have someone else read to you while you learn to recognize the language and make the connections between the sounds and the squiggles.
Once you have a feel for the rules, read things that bend them or outright break them and still manage to work. Figure out why. Understand why "ghoti" has the same pronunciation as "fish" in English. Keep reading.
Write: Write somewhere close to as much as you read, if possible. Do things that work. Do things that should work but don't. By accident, you'll likely do something that shouldn't work but does. (Figure out why.) Do ugly, clunky, and functional things, and then find ways of refining them into beautiful, sleek, and occasionally buggy things.
Write tests. Do things designed to break tests. Do things designed to break systems. Do things designed to repair the damage and make those systems better than they were.
Above all, make sure the documentation gets written. If not by you, by someone. Complete documentation is necessary for everyone, including you a few months in the future, to understand what happened.
Play: Let curiosity guide you. Make things into games, if they look like they'd be fun to do so. Any time you wonder a thing, write it down. Ask it if you can, when you have the opportunity, but if not, investigate it yourself. Take your 20% time to build your own interests and knowledge, and to have fun with the things that you want to have fun with. Talk to your rubber duck around other people. Follow the impulse that says "what would happen if...?" Do things that help ease your pain points, and then release your solutions into the wild for others. (Whether for-profit or not.)
If this sounds like what young children do, then you've got the idea. They talk and ask questions (seemingly incessantly), they sing mnemonic songs, they write a lot, they read a lot (even if it looks like they're just playing games - they're reading the systems and figuring out how to respond to them), and so long as they disguise it as play, kids can get away with just about anything.
We can be a lot more like kids.
Licensing
This presentation is licensed under a Creative Commons 4.0 Attribution-ShareAlike License. Please credit Alex Byrne (abyrne at piercecountylibrary dot org) or HeofHIShirts for the attribution requirements of any derivative works. Or if you like this work and would like to quote it at someone else.
Any content linked to or used in this presentation, and any video or audio recordings of this presentation may not be governed by this license - please check with the appropriate content owners before reusing any content not specifically governed by this license.